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PROCEDE ET DISPOSITIF DE GEMERATtOh! DE LOGICIELS 
EXECUTABLES SUR MESURE ET EVOLUTiFS SAMS PROGRARflMATIOM 
iMFORMATIQUE. 

5 La presents invention vise un proc6de et dispositif de generation de logiciels 

executables sur mesure et 6volutife sans programmation infomiatique. Eile 
s'applique en partlculier a la generation de logiciels de gestion et de pilotage d'un 
centre de profits. 

Le processus de generation de logiciels actuellement connu est base sur la 
10 negoclation d'un cahier des charges entre le client et I'informaticien charge de 
realiser une application informatique repondant au cahier des charges, puis la 
programmation par un informaticien d'un logiciel correspondant au cahier des 
charges negocie. Le client ne maTtrisant pas les contraintes techniques qui encadrent 
le travail de rinformaticien, la negociation est asymetrique et provoque. par elle- 
15 meme, une insatisfactlon du client. En outre, toute modification ulterleure du logicilil 
est soumlse a un nouveau travail de I'informaticien, ce qui gdne revolution de ce 

logiciel. •• 
La pr§sente invention vise a remedier a ces inconvenienfe. En particuller, la 
presente invention vise ^ eviter I'lntervention d'un informaticien dans 1^ 
20 programmation ou la modification d'un logiciel. En d'autres mots, la pr^serite 
invention vise a donner au client : 

- la maTtrise du processus operationnels de generation de I'application, 

- d'eviter que I'application soit soumise aux modules sommaires donnes par les 
infbrmaticiens, 

25 - d'obtenir, en quelques minutes, une application informatique sur mesure, 
repondant integralement ^ ses voeux, sans avoir a mattriser de langage 
informatique. 

Selon un aspect. la presente invention vise un precede de generation de 
logiciel applicatif de gestion d'un processus, caracterise en ce qu'il met en oeuvre un 
30 logiciel systeme commun ^ tous les logiciels applicatifs et en ce qu'il comports : 

- une etape de representation du processus, mettant en oeuvre un tres petit 
nombre de classes d'actions ou objets generiques. typiquement inferieur a vingt. 
dans au moins un diagramme de I'application, 
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- une etape de transcription de chaque objet de chaque diagramme en une action 
correspondant a un objet dote d*attributs, chaque classe d'action ou objet 
generique etant, pendant Tetape de transcription, associe a une interface de 
saisie de donnees d'application, 

- une etape de transcription des rioeuds, erribranchements et feuilles de chaque 
diagramme en une action correspondant a un objet dote d'attributs, 

- une 6tape de pre-compilation au cours de laquelle on verifie que les attributs 
des objets necessaires pour la logique de fonctionnement de Tapplication existent 
et sont convenablement foumis, en syntaxe, 

- une etape de compilation au cours de laquelle les descriptifs de donnees des 
objets dotes d'attributs sont Integres et sont assembles avec le logiciel systeme, 
pour obtenir un logiciel applicatif executable, et 

- une etape d'execution du logiciel applicatif executable. 

Grace a ces dispositions, le client effectue la representation du processus 
correspondant d rapplication par une simple representation graphique en 
diagramme, qui definlt integralement Tapplication informatique qu'il souhaite, sans 
autre contrainte que celle de connaitre le tres petit nombre d'objet gen§riques a 
employer. Des que cette phase est achevee, la transcription peut §tre effectuee par 
simple saisie, par une personne de faible qualification. Les deux stapes restantes, 
pre-compiiation et compilation sont totalement automatiques. 

On obsen/e que les descriptifs d'applications peuvent etre modifies ou 
completes aisement : une nouvelle compilation fournit un executable a jour, 
compatible avec les autres versions, et evolutif, en quelques minutes. 

On observe qu'assembler un certain nombre d'actions standards en un 
diagramme donne un resultat plus simple a controler que du code (par exemple du 
code "C") genere directement Le princIpe est que des actions, qui travaillent sur des 
donnees convenablement organisees, peuvent etre consid6rees comme sures, et 
leur contenu jamais trac§, ce qui evite de longues phases de debuggage. 

Les dSroulements de ces diagrammes sont fixes de fagon permanente dans 
des procedures standard, li suffit de fournir les identiflcateurs d'6crans et de fichiers 
utilises, et ces diagrammes vont les visualiser, modifier les menus au fur et a mesure 
des etapes, etc ... Le mecanisme de la procedure est toujours identique, mais son 
contenu est adapte, sur mesure, aux besoins exprimes par les utilisateurs. Bien 
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entendu. un certain nombre de points d'entree subsiste pour insurer des actions 
partioulieres ^ cheque client, par exemple si le mode de lecture des donn6es est tr^s 
particulier (par exemple, si le fichier n'est pas un fichier standard mais est imports 
d'un autre systeme, la fagon de lire la premiere fiche n'est pas standard, done doit 
5 §tre donnee par le concepteur). Par centre, le fait d'avoir le choix de demander la 
premiere fiche reste standard, done le diagramme consid§r6 est utilisable. 
L'ensemble des infonnations propres a chacun des applicatifs est r§uni de fa^on 
structur6e dans des "cartes" : le concepteur "cable" une carte pour approprier le 
processus standard ^ chaque processus particulier. 
10 Ce principe pennet, par exemple. a une m§me action de visualisation 

d'afficher des ecrans differents sulvant la carte dans laquelle on se trouve, tout en 
conservant les m§mes paramdtres d'appel. II suffit d'avoir modifie auparavant une 
table de param^tres Indexes. 

Ce type d'interprStatlon est fait non pas par Taction elle-m§me, mats par le 
15 m6canisme d'lnterpr^tation des diagrammes fcablage" de ia carte). En d'autref 
termes, une action comporte des donn6es soit d6crites de fagon sp6cifique soft 
decrites par des parametres (carte + num§ro dans la carte). t 
Selon des caracteristiques particulieres. au cours de I'dtape de transcription 
d'objets, au moins une action lance un traitement complet se trouvant ^ un endrolt 
20 distant d'une arborescence correspondant audit au moins un diagramme, et une fois 
celuj-ci termine, retourne ^ son point de depart. 

GrSce ^ ces dispositions, les diagrammes peuvent §tre constitues, modifies et 
mis d jour Ind6pendamment. 

Selon des caracteristiques particull6res, au cours de I'etape d'execution. le 
25 logiciel applicatif executable met en oeuvre une bibliotheque de gestion du 
deroulement des processus correspondant audit au moins un diagramme, ladite 
bibliotheque constltuant un automate qui gere le deroulement des processus et 
execute les operations qui les jalonnent, le deroulement des operations etant defini, 
dans le referentiel applicatif, a I'aide de la methode, en decrivant les flux reels. 
30 Ainsi. la seule mise en oeuvre de la methode et de la transcription permet de 

programmer une application. 




Selon des caracteristiques particu!ieres, au cours de Tetape de compilation ou 
au cours de Tetape d'execution, ii met en oeuvre un moteur qui comporte un 
superviseur charge de reconnaTtre la configuration materielle et de communication. 

GrSce a ces dispositions, il est inutile de generer la configuration dans 
5 rapplicatif. La gestion des ^changes se fait par des taches sur I'ensemble d'un 
ecran, sur certains champs ou par des messages envoyes a Tutilisateur par le 
deroulement du processus. 

Selon des caracteristiques particulieres, le moteur gere une ou plusieurs 
bases de donnees d'apres un descriptif des fichiers de donnees fourni par le 
10 referentiel applicatif, c'est-a-dire une liste des informations contenues dans chaque 
fiche et la liste des index d'acces, avec une liste des champs servant a constituer 
chacun de ces index, les liens entre des codifications multiples d'un meme item dans 
plusieurs services, plusieurs sites ou plusieurs entreprises. 

Selon des caracteristiques particulieres, les bases de donnees sont 
15 synchronisees selon une frequence determinee par le diagramme, d la demande ou 
avant certains evenements predetermines. 

Ainsi, les bases de donnees peuvent §tre synchronisSes toutes les nuits, 
lorsqu'un utillsateur autoris6 le demande ou pour un 6venement le necessitant, par 
exemple pour realiser un devis client (les stocks et les prix instantanes devant, par 
20 exemple, etre connus pour cette operations). 

Selon des caracteristiques particulieres, Tetape de transcription d'objets 
comporte, pour programmer chaque action : 

- une etape de nommage au cours de laquelle on donne un nom a ladite action, 

- une etape de definition de fonction. au cours de laquelle on met ladite action en 
25 correspondance avec une tSche, et, 

- une etape de definition d'information, au cours de laquelle on designe les 
informations qui seront traitees dans Taction. 

Les actions sont enchamees suivant leur ordre fonctionnel dans des 
diagrammes. Les actions ramenant toutes a des codes d§finis, il est possible de 
30 repr6senter ainsi les structures de controle classiques telles que branchement, 
boucle, test, etc ... Ces controles sont eux-memes effectues par des actions. 
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Selon des caract6ristiques partlculi6res, I'etape de compilation remplace le 
nom d'action donn6. au cours de I'etape de nommage. par le transcripteur. par un 
index dans une table de taches. 

Gr&ce S ces dispositions. I'etape de transcription peut §tre assez intuitive, le 
5 transcripteur cholsissant un nom d'action qui lui semble ais^ment reconnaissable. 
tout en permettant un fonctionnement automatique et efficace de I'application 
compilee. 

D'autres avantages, buts et caracteristiques de la presente invention 
ressortiront de la description qui va suivre, faite en regard des dessins annexes dans 
10 iesquels : 

- la figure 1 repr^sente, schematiquement, les composants du systeme objet 

de la presente invention, 

- la figure 2 repr^sente. schematiquement, des composants mis en oeuvre par 
le proc§d§ objet de la presente invention, et. > 

IS - la figure 3 repr6sente, schematiquement, les etapes mises en oeuvre par % 

proc6d6 objet de la pr^ente invention. ' 

Dans la figure 1 sont repr§sentes une methode 10 de description de 
processus et de generation de diagramme 150. un g6n§rateur d'applicatioh 
informatique 20 mettant en oeuvre des objets generiques 30, des composanfe 

20 proc6duraux 40 et des composants applicatifs 50 pour generer un logiciel executable 
60 comportant un automate 70 mettant en oeuvre les composants applicatifs 50. 

Conform^ment a la methode 10. methode de description cybernetique des 
processus, de quelque nature qu'ils soient, pour obtenir un descriptif sous forme de 
macro-Iangage. appele "r^ferentiel applicatif, le client definit d'abord sont processus 

25 en grands ensembles, en decrivant leurs relations (par exemple gestion des stocks. 
comptabiIit6, decision d'organisation de travail, prise de commande, alertes 
necessaires ...). Dans un second temps, chaque ensemble est consid6r§ et 
decompose en sous-ensembles de tSches, et ainsi que suite jusqu'a ce que toutes 
les actions du processus soient d§crites en ne mettant en oeuvre que des 

30 diagrammes composes d'actions correspondant. chacune d un d'objet g6nerlque de 
I'une des classes suivantes. dote d'attributs necessaires au fonctionnement des 
diagrammes : 

a) entreposage structure de donnees. 
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b) transmission de donnees, 

c) supervision. 

d) communication avec les utilisateurs, 

e) deroulement du processus, 

5 f) systeme op6rationnel (capteurs de donnees et de signaux, emission de 

messages et d'alertes), 

g) pilotage a deux niveaux (previsionnel ou operationnel), 

Le macro-langage defini par la methode 10 decrit les processus pour 
constituer une couche logique, au dessus de la couche des programmes 
10 informatiques. A la base de la creation de ce macro-langage, il a ete cree une 
typologie des traitements Informatiques. 

On observe que le diagramme lui-m§me est compose d'une racine. 
d*embranchements, de noeuds et de feuilles, chacun de ces composants 6tant aussi 
repr6sente par une action. 
15 Avec cette methode 10, le client d6finit les limites du probldme/processus pour 

lequel il souhaite mettre en oeuvre un logiciel executable sur mesure et ses relations 
avec I'environnement il peut y introduire exactement ce que font les differentes 
personnes du centre de profit, les 6v6nements exceptionnels prevus (par exemple 
les vacances de collaborateurs, les arrets d'une machine en maintenance), les aleas 
20 (par exemple une commande urgente ou une panne machine) dont il souhaite tenir 
compte et les criteres de decision d'alerte dont ils souhaitent disposer. 

Pour determiner la typologie indiquee ci-dessus, les operations repetitives 
realisees au cours du deroulement d'une application informatique ont 4te recensees : 

- ces operations sont identiques, quel que soit le sujet traite, 
25 - elles sont en nombre limite, 

- elles peuvent etre reparties en sept classes (classes "a" a "g", ci-dessus) 
Chacune des sept classes d'operations est traitee selon une approche 

orientee « objet », en encapsulant les regies internes propres S la classe, regies de 
nature determinee repetitive, s'agissant du comportement d'objets infomiatiques (par 
30 opposition aux objets des domaines appllcatlfs de gestion, soumis a I'aleatoire). Les 
caracteristiques propres a chaque classe, et necessaires pour faire fonctionner les 
regies internes, ont ete inventoriees et reunies dans des « structures » d'attributs. au 
sens informatique du terme « structure ». 



Ainsi, dans une deuxieme etape, les diagrammes representant le deroulement 
du processus de gestion ou de pilotage sont saisis en mettant en oeuvre des ecrans 
de saisie qui guident Toperateur at lui interdisent de faire certaines saisies 
incorrectes ou incompletes. Chaque objet est dote d'attributs definissant des 
5 donn6es dans des formats predetermin6s (types de donnSes, quantite, longueur et 
unit6), des elements de stockage des donn§es (dans des fichiers permanents et/ou 
avec une date de validite), des droits d'acc6s des differents utilisateurs et les 
interfaces qu'ils utiliseront, des elements de decision avec comparaison d'options 
(decision : acheter ou fabriquer, par exemple). Un support numerique permet de 
10 representer une application en remplissant les champs d'attributs dans les structures 
liees a chaque classe d*objet (par exemple, un ecran est totalement defini dans deux 
structures qui decrivent Tensemble de i'ecran et chaque champ de Tecran). 

Le generateur 20 effectue les operations suivantes : 

- il verifie la syntaxe. 

15 - il verifie ['existence des informations necessaires, 

- il gSn^re la base de donnees pour Tapplication, et 

- il compile Texecutable pour foumir une application informatlque sur mesure j 
Le generateur 20 effectue une pr6-compilation qui verifie que les attribiits 

necessaires pour la logique de fonctionnement de Tapplication existent et sont 

20 convenablement remplis (en syntaxe et non en contenu)- 

Chaque action est associee a une interface de saisie. Cette particularity est 
un des aspects de la pr6sente invention. La compilation accomplit ensuite 
Tintegratlon des descriptifs de donn6es d'application et les assemble avec le logiciel 
systeme, pour obtenir un executable. Le logiciel systeme est permanent, commun a 

25 toutes les applications. 

^automate 70 comporte un moteur 71 et met en oeuvre des fonctionnalites. 
Le moteur 71 represente Tordre de mise en oeuvre des fonctionnalites et les 
procedures correspondant aux diagrammes de deroulement de Tapplication 
informatique. Le moteur 71 relie chaque action a Tune de ses taches types 30 (il y en 

30 a une soixantaine) au moyen de mecanismes d'execution r6partis en sept classes. 

Le moteur 71 poss6de un ensemble predetermine et permanent de taches 
programm6es informatiquement, performantes et controlees, appelees dans des 
actions applicatives. Ces actions sont executees par le coeur du moteur 71 , suivant 



un ordre defini dans des diagrammes organises sous forme d'arborescence, avec un 
mecanisme de controle du retour des taches conduisant a la poursuite du 
diagramme en cours, ou a un branchement vers un autre diagramme ou un autre 
sous processus. Par exemple, une tache de calcul se poursuit sur la tache suivante 
5 dans le diagramme en cours, alors qu'une tache de comparaison conduit 
generalement a un branchement defini par la description de Taction appelant la t§che 
de comparaisons. 

On observe que les descriptifs d'applications peuvent etre modifies ou 
completes : une nouvelle compilation fournit un executable a jour, compatible avec 

10 les autres versions, et evolutif. Dependant, si on change le descriptif d'un format de 
donnees, il faut transferer les donnees dans un nouveau fichier, avec le nouveau 
format, ceci grace a une procedure automatique appartenant aux composants 
proceduraux 40. En revanche, on peut ajouter des champs, dans la limite de la place 
disponible dans le fichier, ou 6tendre les dimensions du fichier avec la procedure 

15 automatique 6voquee ci-dessus. 

Gr§ce ^ la mise en oeuvre de la pr6sente invention, on transforme une 
description procedurale en executable sans la moindre ligne de langage 
informatlque. Selon un de ses aspects, la presente invention d6fmit un macro- 
langage et/ou une nouvelle couche systeme. 

20 On comprends aisement que, lorsque le client souhaite une modification, 

on modifie !e schema du diagramme et. apres traitement, il obtient un nouvel 
executable sans qu*il soit necessaire de mettre en oeuvre des competences 
d'informaticien. 

Dans les logiciels connus, le deroulement des echanges entre le logiciel et les 
25 utilisateurs est conduit par le systeme graphique, Ici, c'est le logiciel qui a la maitrise 
du deroulement des operations, y compris avec le systeme graphique. On obtient 
ainsi I'independance par rapport aux syst§mes externes, la possibilit6 de 
communiquer indifferemment avec differentes interfaces, par identification de 
rinterlocuteur. 

30 Le moteur 71 execute les operations du processus d'une fagon neutre et 

independante du domaine d'appHcation. grace a des m§canismes d'ex6cution Issus 
d'une typologie rigoureuse des modes de fonctionnement de Tinformatique et repartis 
en sept classes. 



On observe que. dans la douzaine de structures utilisees (structure au sens 
informatique du terme), trois sont des structures dynamiques, une est una structure 
de navigation et les autres sont des structures descriptives de donn^es. 

Des objets proceduraux applicatifs repetitifs et communs a tous types 
5 d'application sont utilises : saisie de fiche simple, saisie de fiche avec iiste attaches 
(par exemple les mouvements de stock pour un produit), impression, alerte, 
reconfiguration de fidiiers de donnees, liaisons avec d'autres systemes d'information. 
S'y rattachent un m^canisme de d^roulement et un superviseur qui constituent le 
"coeur" du moteur 71 . 

10 On va maintenant d^crire d'autres objets mis en oeuvre confomi^ment & la 

pr^sente invention. 
1/ Les donnees (ou "rubriques") 

- nom de la donnee 

- type alphanum§rique, nombre 
15 - taille 

- cadrage 

- nombre de decimates et signe (si donn§e num6rique) i 
On observe qu'une rubrique est d§finle une seule fois pour une application et pe^t 

etre appel§e dans tout fichier ou interface de cette application. Une rubrique porte le 
20 m§me nom dans toutes les applications, mais sa description est adapt6e a«x 
besoins de chaque appllcatif : automatiquement les fichiers. interfaces et traitemerits 
disposent des specifications propres a I'application. 
21 Les flciiiers de donn6es (ou tables) 

- le nombre de donnees dans le fichier et la dimension de I'espace sur disque 
25 ou en memoire pour la gestion de chaque fiche, 

- la description des donnees de chaque enregistrement du fichier et leurs liens 
avec des donnees d'autres fichiers ou ecrans 

o nom de la rubrique, 
o liens avec d'autres fichiers ou ecrans 
30 3/ Les interfaces utilisateurs (6crans) 

- le nombre de donnees dans I'ecran et la dimension de I'espace de gestion de 
r^cran 
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- la description de chaque donnee de l'6cran fichier. de son comportement dans 
les echanges a travers Tinterface homme-machine et ses liens avec des 
donnees d'autres fichiers ou ecrans : 

o nom de la rubrique, 

o Hens avec d'autres fichiers ou ecrans, 

o type d*objet interface homme nnachine : libelle. texte. boutons radio. ... 
o positionnement sur T^cran, 

o mode de saisie : en mode creation de cle (mode d'acces au fichier, par 
exemple par nom ou par localisation) ou de selection, en mode courant 
(dans lequel on ne modifie plus de cle, sauf si elle est modifiable), 

o traitements lies a la donnee, en debut et en fin de saisie (a fin de 
controle, de traitements, ...), 

o champ sur lequel retoumer en cas d'erreur 
4/ Les espaces de gestion dynamique des fichiers et ecrans, lors de leur utilisation 

- dimension des espaces. 

- valeur des donnees de la fiche ou de Tecran en cours d'usage (identification 
des donnees, quantites, montants, ...). 

- etats des traitements (phases de recherche d'une fiche, de traitements de la 
fiche, de validation de fiche), 

5/ Un navigateur. tra9ant pour chaque utilisateur, la route suivie au cours du 
deroulement de son travail et assistant une hyper-navigation par la possibilite 
d'atteindre directement des processus distants, puis de revenir au processus en 
cours : 

- etapes du parcours. 

- travaux realises au cours de Tetape. avec un tragage des liens avec (es 
processus distants, assort! d'un m6canisme de retour automatique en arriere, 

6/ Des diagrammes de flux 

- description de diagrammes de traitements, avec des branchements soit 
choisis par Tutilisateur (par exemple par utilisation de menus), soit imposes 
par la logique du contexte (aiguillage sur deux processus differents de calcul 
d'un prix de revient suivant le caractere achete ou fabrique d'un produit), 



- sur chaque branche. appel a des actions de traitement : calcul. affectation de 
valeurs S des donnees, comparaisons, interface avec des fichiers ou des 
ecrans, 

7/ Des messages et menus 
5 - messages d'infomfiation. 

- messages d'alerte, 

- choix de traitements par des menus 

D'une maniSre generate, ia pr§sente invention vise un syst6me logiclel 
composite associant : 
10 1/ un moteur 71 capable de realiser de fagon standard et en temps r6el : 

- des procedures de traitement d 'informations de toutes natures, soit en 
simulation d'hypothdses futures, soit en mettant en oeuvre les evenements 
reels, 

- sous fonne d'ensembles et sous-ensembles de traitements, coordonnes et 

15 possedant des capacites de boucles de feed-back fournissant et/du 

'*> 

echangeant des informations en retour, V 

If 

- avec la mise a disposition de tableaux de bord permanents et lie 
declenchement de signaux d'alerte pr6sentes instantan^ment ou en temgs 
utile aux utiiisateurs concern6s (on definit done qui doit §tre alerte et quand, 

20 dans le diagramme). 

2/ un referentiel applicatif, cree a Taide de la methode 10, d§crivant les informations 
et leurs traitements specifiques et r6pondant exaotement aux besoins de Tentreprise 
et des utiiisateurs : 

- pour un processus de gestlon, ou un ensemble de processus en interrelation, 
25 - sous une forme de systeme et sous-systemes avec des boucles de feed-back, 

- avec une description sous forme banale et non informatique des flux reels, si 
necessaire amenages pour plus de performances et de reactivite des acteurs 
et du systeme dans son ensemble. 

3/ un generateur 20 de logiciel executable sur mesure : 
30 - le logiciel executable est genere sans programmation. en associant le moteur 
71 (paragraphe 1) et le referentiel (paragraphe 2) de rapplicatif, 

- la description sur mesure des besoins exprimes dans le referentiel est traduite 
automatiquement dans le langage du moteur 71 




- le generateur de logiciel executable est lui-meme construit avec le moteur 71 
standard avec son propre referentiel applicatil 

D'une maniere plus detaillee, le moteur 71 est un ensemble de bibliotheques 
de fonctions C. Java at Internet, permettant une gestion de processus, simples ou 
5 complexes, avec : 

- un traitement en temps reel des evenements et des informations qui leur sont 
liees, 

- la detection de situations anormales accompagnees d'un systeme de signaux 
d'alerte, 

10 - ridentlfication complete des ev6nements avec un stockage des donn^es sous 
forme d'une base de connaissances a jour en permanence. 
Chaque bibliotheque est specialisee dans un domaine particulier, et liee aux 
autres dans un schema de relations fonctionneiles. Les fonctionnalites et donnees 
utilisees dans chaque bibliotheque sont formalisees dans un langage et avec une 
1 5 syntaxe propre au moteur 71 . 

La bibliotheque de gestion du deroulement des processus constitue 
rautomate70 qui gere le deroulement des processus et execute les operations qui 
les jalonnent. Le deroulement des operations est defini dans le referentiel appiicatif, 
a Taide de la methode 10, en decrivant les flux r6els, si n6cessaire amenag6s pour 
20 plus de performances et de r§activite, d6s la conception et facllement adaptables 
lorsque Torganisation change dans le temps. 

Les processus sont structures sous forme d'arborescences de flux 
operationnels, Ces arborescences representent les flux du reel, tels qu'ils ont et6 
analyses avec les utilisateurs a Taide de la methode 10. Le moteur 71 execute 
25 Tenchalnement des operations sur chaque branche du flux en cours de traitement. 
Des branchements sont declenches : 

- soit par un choix de Tutilisateur a Taide d'un menu, 

- soit par Evaluation de la situation conditionnant les etapes suivantes : 

o choix d'une branche parmi plusieurs pour poursuivre le processus, 
30 o mise en oeuvre de signaux d'alerte et de boucles de feed-back 

(asservissement) 

Chaque processus est jalonne d'operations ou actions. Le moteur 71 execute 
la suite de ces actions en faisant appel d une bibliotheque de tSches. 




Les taches utilis6es, illustiees en figure 2, associ§es au deroulement des flux 
de la realite, sont de cinq types : 

a) taches complexes 21 d'appel a d'autres processus ou sous-processus, 

b) taches complexes d'alguitlage 22, 

5 c) taches simples 23 de calculs. de traitements d'informations. 

d) taches de communication et d'6changes 24 avec les utilisateurs, 

e) taches de transactions 25 avec des bases de donn§es. 
Chacun de ces cinq types va §tre decrit ci-dessous. 

a) Taches complexes 21 1 d'appel a d'autres processus ou sous-processus 
10 - ces taches lancent des applications, sous forme d'un nom de processus, 
chaque processus etant assorti de droits d'acces ; 

- chaque personne ayant un code d'acces regoit 

o fattribution d'un processus initial par lequel elle entre dans le systeme, 
o une definition de ses droits qui guident ses acces a d'autres processus 

15 en cours de navigation, ■■ 

- les t§ches d'appel a des processus permettent soit d'acc§der ^ des 
« briques » fonctionnelles communes, soit de pratiquer une « hyf^fer 
navigation » entre des fonctions et processus differents. \ f 

o Le branchement sur un autre processus se tennine par le retdur 
20 automatique sur le processus en cours (hyper-navigation) • 

- les « taches d'appel de processus » permettent de rendre tres simple et 
souple I'utilisation commune de processus et de declencher quatre types de 
processus : 

o un sous-processus 211 falsant suite au processus en cours, 
25 o un processus distant 212, 

o un sous-processus standard 213, commun & plusieure processus, 
o un applicatif g§n§rique complexe 214, commun a toutes les 
transactions avec les utilisateurs 
Un sous-processus 211 se declenche ^ la suite d'un aigulllage issu d'un choix 
30 de I'utilisateur par utilisation d'un menu (le sous-processus a le nom du processus 
origine, complete du num6ro du choix dans le menu) ou d'une evaluation de la 
situation (le referentiel applicatif peut soit donner un nom sp6cifique au sous- 
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processus, soit conserver le nom du processus origine. en le completant d'une lettre 
(par example un « e » en cas de detection et de traitement d'une erreur). 

Par un processus distant 212. I'utilisateur evite un parcours difficile a travers 
des suites de menus. L'utilisateur accede directement S des tSches annexes par une 
« hyper navigation ». Quand un processus distant 212 se temriine. la navigation 
ramene au processus appelant. Ce m§canisme de processus distants pemiet de 
partager sans difficult6s un processus entre plusieurs utilisateurs, services ou 
fonctlons. Par exemple. la prise de commande peut se faire par un commercial 
§loign6 ou proche, aussi blen que par un service d'administration des ventes local. 

Un sous processus standard 213 correspond a une procedure elementaire 
totalement repetitive et commune a plusieurs processus. Ces processus standards 
213 peuvent etre definis pour une entreprise, compte tenu de ses besoins 
particuliers, pour un ensemble d'entreprises, auxquelles s'imposent las m§mes 
logiques ou regies de base. Par exemple, un calcul de stock reel ou pr6vlsionnel 
peut gtre realise au magasin, aux achats, dans un calcul automatlque de sortie de 
stock, lors d'un ajustement d'inventaire. 

Un applicatif g§n§rique complexe 214 est commun d toutes les transactions 
r6alis6es par les utilisateurs. II fait partle des fonctionnalitds offertes par le proc6d§ 
objet de I'invention : 

- saisie simple, par exemple saisie ou mise a Jour d'une fiche client, d'une fiche 
produit, 

- saisie de liste, par exemple saisie ou mise it jour d'une fiche nomenclature 
(liste des composants attaches a une nomenclature), 

- declenchement d'alerte dans les processus de pilotage, par exemple 
depassement de delai, 6cart anomnal entre budget pr6visionnel et realise. 

- impression, par exemple. Impression de certaines donn6es clients : un client, 
une categorie de clients, la totality du fichier client (liste des clients avec leurs 
adresses, ou leurs chlffres d'affaires, leurs commandes en cours, ...). 
T§ches complexes d'aiguillage 22. A chaque noeud de I'arborescence, les 

aiguillages entre plusieurs branchements sont d6clench§s par trois voles : un choix 
221 de Tutilisateur, par une navigation avec un menu, une identification d'une 
situation precise 222 comportant plusieurs possibilltes de traitement (par exemple, 
dans le calcul de prix de revient d'un produit a partir de sa nomenclature, les calculs 




du cout d'un produit achete at celui d'un produit fabrique sont differents et donnent 
lieu a des sous-processus differents), una evaluation d'une situation 223 sur ia base 
de criteres de contrSle avec declenchement d'alertes, de boucles de feed-back (par 
example coQts ou delais anormaux). 

5 Les t§ches simples 23 de calculs ou de traitements d'information se 

caraoterisent par le fait qu'elles seules traitent directement les informations, Le 
proc6de de Tinvention inclut les informations utiles a la conduite et S la maitrise des 
flux et prevoit le pilotage et Taide d la decision operation nelle. Le dispositif utilise des 
capteurs et des regies de contrdle au plus pres des evenements. Le processus 

10 recueille les informations des qu'un evenement survient, en temps reel, et declenche 
en tant que de besoin des signaux d'alerte aupres des personnes chargees des 
decisions operationnelles. dans les delais utiles (definis par le diagramme) pour 
chacune d'elles (immediat pour les decisions d'execution, ou avec un delai approprie 
a la bonne efficacite des decisions degestion). 

15 Les calculs 231 comportent les operations de base, avec prise en compte 

nombre de decimates, tes cumuls et ventilations et Tattrlbution de valeiirs 
alphabetiques ou numeriques, 5 

Les comparaisons 232 sont effectuees entre des donnees alphabetiques pu 
numeriques. D'apres le resultat d'une comparaison, on declenche des branches de 

20 traitement appropriees. 

L'envoi de message 233 est effectue vers Tutilisateur ou vers d'autres 
utilisateurs (alerte), en fonction de resultats constates a un poste. 

Les transferts 234 sont relatifs a des liens entre des champs d'un ecran ou 
d'un fichier avec des champs d'autres ecrans ou fichiers, soit en importation, soit en 

25 exportation. Un transfert ponctuel peut aussi etre effectue entre des champs d*origine 
et des champs de destination. 

Le traitement de dates 235 concerne Tattribution de la date et de Theure 
« systeme », le calcul de dates de debut et de fin d'operations d'apres un delai ou 
calcul d'un delai d'apres des dates de debut et de fin, et la comparaison de dates, 

30 Les taches de communication et d'echange 24 avec les utilisateurs se font par 

Tintermediaire d'un terminal informatique, soit a travers un reseau classique, soit par 
un navigateur internet Le moteur 71 comporte un superviseur charge de reconnaitre 
ia configuration materielle et de communication (reseau local, intranet, internet. ...) 
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de I'utj'lisateur, et il est done inutile de generer celle-ci dans rappllcatif. La gestion 
des echanges se fait par des laches sur Tensemble d'un ecran, sur certains champs 
ou par des messages envoyes a Tutllisateur par le d6roulement du processus, 
Les taches de communication et d'echange 24 comportent : 

- la creation et destruction d'un ecran (activation de Tecran et affectation de 
m6moire) 241. 

- Taffichage d'une page complete 242, avec son titre, ses libelles et ses champs 
dMnformation puis effacement de la page, 

- Taffichage d'informations dans des champs 243 et modification d'ecran, y 
compris affichage de Tensemble des informations (par exemple a la lecture 
d'une fiche), Taffichage de champs modifies (par exemple a la suite de calculs 
declenches par la saisie d'un champ et influengant d'autres champs, 
attribution de valeur dans un bouton radio, ...) 

- la gestion des autorisations de modification 244, sur les constituant des codes 
ou noms servant a lire des fiches sur la base de donnees (acc^s en mode de 
selection, champs de des modifiables ou non), ou sur les informations 
courantes de la page d'ecran (acc§s en mode de mise a jour, acces en simple 
consultation ou champ sans objet contextuel), 

- le positionnement particulier sur un champ 245, y compris champ obligatoire a 
remplir et champs a corriger en cas d'erreur de saisie reconnue, 

- I'envoi de message 246, y compris information a Tutilisateur, en particulier en 
cas d'erreur, Taffichage d'une boTte de dialogue a acquitter avant reprise de la 
saisie d'ecran, ou Taffichage d'un message d'information durable en bas de 
I'ecran, 

- Teffacement de I'ecran 247, y compris passage provisoire d un autre ecran et, 
en fin d'utilisation d'un ecran, avant sa destruction. 

On observe que le dessin des ecrans est adapte a chaque categorie 
d'utilisateurs, en fonction des besoins de chacun. Leur simple description dans le 
referentiel applicatif suffit a faire fonctionner les tSches de gestion des echanges 
indiques ci-dessus. 11 est facile et rapide de les adapter en tant que de besoin, par 
simple modification de leur descriptif. Les informations sont presentees sous forme 
d*objets graphiques et specifiees comme telles (champ de saisie ordinaire, boutons 
« base de donnees », boutons radio verticaux ou horizontaux, cases a cocher. 




languettes, editeur, table, code a barres, llbell^, lien hypertexte). Les champs 
d'informations sont accessibles en mise a jour, accessibles seulement en 
consultation ou invisibles ^ destination par exemple de champs d'identificateurs, de 
champs intemnediaires de calculs, ou de champs d'informations elaborees a 

5 destination de tableaux de bord distants. 

Concernant les droits d'acces, tout acces aux processus est soumis d un 
controle des droits de la personne en ligne. Chaque personne accedant a I'applicatif 
ne peut « voir », modifier, que ce qui lui est attribu§ par les droits qu'elle a re^u avec 
son code d'acces. Ces droits peuvent changer dans le temps, sous la responsabilit6 

10 d'un gestionnaire des accds. Une personne ayant des droits eleves a interet ^ 
recevoir plusleurs codes d'acces avec des droits de plusieurs niveaux, afin de limiter 
les risques d'acces intempestifs, par d'autres personnes, a des informations 
confidentielies. 

La presentation des documents imprimis est consid6r6e comme celle d'un 
15 Scran avec la limite d'un acc^s ^ consultation, avec la possibility de disposer de 
dimensions de « pages » plus grandes. . * 

Les taches de transaction avec des bases de donn§es 25 comportent : 

- I'initialisation et la liberation des espaces d'informations liSs a un fichier 251, ^ 

- la creation ou la mise ^ jour de fiches 252 par ecriture sur la base destinataire 
20 (chaque fiche re^oit automatiquement un numero d'identification univoque qui 

sert de lien entre des items apparent^s, sans que des modifications de code 
ou d'appellation aient une quelconque consequence, 

- la creation de cles d'acces pour lecture de fiche particuliere 253 : acces 
possible par des codes, des noms, des p6riodes de validity, des liens avec 

25 d'autres fiches, ... (I'accSs ^ la base de donnSes en multi-codification pemnet 

de rendre les informations accessibles a chaque categoric d'utilisateurs en 
respectant sa culture propre, par exemple les codes produits sont souvent 
differents pour la technique et pour le commercial, voire entre plusieurs 
etablissements; entre plusieurs processus autonomes (exemple : liaisons 

30 entre les differents sen/ices fournis par une banque a un m§me client). 

- la lecture d'une fiche 254 (la fiche est lue sur une ou plusieurs cl§s d'acces § 
preciser : code, nom. identificateur, ... 
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- la lecture d'une liste de fiches ayant un rattachement commun 255 (par 
exemple las mouvements de stocks rattaches a un produit, composants d'un 
produit, lignes de commande, liste des commandes en cours pour un client, 
liste des commandes pour un produit), 

- la suppression d'une fiche 256. selon des modalltes de contrdle 
pr6d§terminees (par exemple. ne pas supprimer une fiche produit si elle 
possdde un stock ou si une ligne de commande en cours y est rattachde), 

- le parcours d'un fichier pour operer un traitement systematique sur toutes les 
fiches, sur un ensemble de fiches entre deux bornes, ou sur des fiches ayant 
une meme racine (par exemple, impression de tout ou partie d'un fichier, 
valorisation de marges sur toutes les commandes d'un m§me client, d'un 
agent commercial, d'une region, ... 

Le moteur 71 gere la ou les bases de donn§es d'apres le descriptif des 
fichiers de donnees foumi par le referentiel appllcatif, c'est-a-dire la liste des 
inforrnations contenues dans chaque fiche et la liste des index d'acces, avec la liste 
des champs sen/ant a constituer chacun de ces index, les liens entre des 
codifications multiples d'un m^me Item dans plusieurs services (commercial et 
technique), plusieurs sites ou plusieurs entreprises (clients - foumlsseure, societes 
fuslonn§es, ...), les bases de donnees 6tant alors synchronls^es selon une 
frequence determinee par le diagramme ou a la demande ou avant certains 
evenements (par exemple pour realiser un devis client). 

On observe, concernant revolution du refdrentiel applicatif dans le temps, que, 
dans certaines limites de dimensions de chaque fiche, contr6I§es par le moteur 71, il 
est possible de completer les informations contenues dans un fichier. Si les formats 
des informations utilisees dans I'entreprise se modifient dans le temps, il est aise de 
maintenir les donnees acquises dans le pass§ par une procedure systeme du moteur 
71. 

La blblioth^que de liaison 26 est partagee entre le r^ferentiel applicatif et le 
moteur 71. Les informations n6cessaires ^ I'execution des t§ches doivent etre 
specifi6es en tant que de besoin et le moteur 71 les rattache a sept types : 

a) menus et choix 261, 

b) messages et alertes 262, 

c) champs d'information et format de donnees 263, 
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d) designations des infonnations 264. 

e) fichiers265, 

f) interfaces visuelles 266, §crans ou pages internet, 

g) branches de processus et taches 267. 

Les menus et choix 261. Les tSches d'aiguillage d^clenchees par les 
utilisateurs comportent des informations de type « menus et choix ». Les utilisateurs 
se voient proposer un menu § chaque fois que leur intervention est n§cessaire pour 
choisir entre plusieurs sous-processus et poursuivre la navigation. Le proc6d6 
nomme « choix » chacun des elements du menu. A chaque choix est lie une branche 
du processus. Chacune des branches est dotee d'un code d'acc§s : si Tutilisateur ne 
possede pas les droits necessaires, le menu filtre et ne propose par le choix 
correspondant. 

Les messages et alertes 262. Le precede nomme « messages » les echanges 
declenchis au cours de transactions avec un utilisateur. Le procede envoip, 
exclusivement ^ I'utilisateur, des messages d'information pour faciliter sa tache ^t 
des messages d'anomalie et d'erreur lorsque celles-ci sont detect6es. Le proc^^e 
nomme. « alerte » I'envol d'informations de pilotage ^ tous les utilisateurs concemes 
lorsqu'il ddtecte des anomalies, au cours d'un processus. Les alertes, envoy6e^:t.a 
distance, sont d'une autre nature que les messages et sont rattach^es A Aa 
procedure standard de gestlon des alertes. Les taches d'echanges et de 
communication avec les utilisateurs se font en temps reel. 

Les champs d'information 263. Chaque element d'une liste d'informations 
dans un fichier et dans une interface visuelle est nomme un « champ ». Pour les 
champs d'un fichier. la specification du fomnat de chaque information indique la taille 
de I'infomiation et reserve en consequence la place necessaire pour les stocker sur 
disque. Lors de la generation du logiciel, la base de donn^es est automatiquement 
creee ou mise a jour. Pour les champs d'un §cran, d'une page internet ou d'un 
imprim§, leur presentation peut atre faite suivant la demande de I'utilisateur et 
changSe ais^ment. 

Chaque champ possede un nom et un format. Chaque entreprise utilise un 
ensemble de donn§es de base: r6f6rences techniques et commerciales des 
produits, prix unitaires. montant d'une facture, temps, couts. delais d'une commande. 
chiffre d'affaire hors taxes et toutes taxes comprises. ... 



Le proc6de nomme « format des donn6es », la specification du format de 
chacune de ces donn^es. Ce format des donnees est utilise pour reserver la place 
n§cessaire dans les fichiers, pour afficher correctement les informations et pour 
controler la saisie des informations. L'attribution d'un format d une information 
specrfie sa presentation et sa dimension : type attribue (donnee alphanumerique, 
code numerique, nombre, date, ...), description (nombre de caractere, cadrage, 
presence 6ventuelle d'un signe, nombre de chiffres de la partie entiere et nombre de 
decimates, numero du mois inferieur ou §gale a 12, numero de la semaine inferieur 
ou 6gal a 54, jour dans le mois inferieur ou §gal a 31 , heure inferieure ou egale a 24, 

Le precede gere une codification multiple (multi-codification) pour tenir compte 
de references differentes pour un m§me objet. par exemple r6f§rences techniques et 
commerciales, liens entre processus distincts, r6f§rences difP§rentes entre plusieurs 
sites ou soci6tes appartenant au m§me groupe, ou plusieure entreprises liees 
economiquement (clients - foumisseurs, societes fusionnees, ...). 

Designation des informations 264. Le proced6 identifie par une designation les 
infomiations presentees sur les supports de communication avec les utilisateurs. 
Chaque information d'une interface est presentee avec une designation. Plusieurs 
designations peuvent §tre utilisees pour tenir compte des differences de langue ou 
de fonction des utilisateurs. 

Fichiers 265. Le precede definit la structure des informations dans les fichiers 
et I'organisation de leur stockage en base de donnees. Les fichiers recueillent des 
ensembles d'infomiations structurees. Une fiche est une structure de fichier (par 
exemple fiche-client) comporte une liste d'informations definies par un nom et un 
format. Chaque fiche d'un fichier peut etre atteinte par plusieurs cles d'accds 
differentes suivant la preoccupation de I'utilisateur. ou son besoin immediat. Les 
evenements sent identifies en temps reel avec des etiquettes appropriees ^ la 
situation vecue. La base de donnees constltue une base de connaissances en 
permanence d jour. 

Interfaces visuelles 266, ecrans ou pages internet. Le precede definit 
Torganisation des informations pour leur presentation aux utilisateurs. Les interfaces 
visuelles representent un ensemble d'informations qui sent affichees avec leur 
designation sur un ecran d'ordinateur, une page internet, un imprime. Comme pour 




tes fichiers. une interface visuelle comporte une liste d'informations definies par un 
nom et un format, ainsi qu'un lien avec les donnees correspondantes stockees dans 
las fichiers. Chaque tnfomiation est dotee d'attributs precisant leur presentation 
visuelle. leur mode de traitement ou de salsie. Les interfaces visuelles peuvent etre 

5 pr6sent§es sous une fomne appropri§e a chaque utilisateur. et modifi§es pour 
repondre S de nouveaux utillsateurs ou de nouveaux besoins. 

Branches de processus et tSches 267. Chaque branche de processus est 
representee dans un diagramme et refine la description des flux reels, obtenue avec 
le r§ferentiel applicatif : nom du processus, enchaTnement des operations, noeuds de 

10 branchements, droits d'acc^s au processus (services, postes agrees). Chacune des 
operations doit etre decrite : nom de I'operation, nom de la tache du moteur 71 qui 
devra etre executee, parametres de I'operation, suivant la syntaxe determinee pour 
chacune des taches existantes. 
Le referentiel applicatif. 

15 Ge referentiel est cre6 en association avec les utilisateurs concernes par \e 

processus S informatiser, d'apres la situation existante, et en etudiant d'eventuell^s 
ameliorations, facilitees par I'emploi d'un outil infomnatique. Une fois I'accord des 
utilisateure obtenu. le i^ferentiel est numerise (par exemple. par saisie ou par lecturp 
optique ou sonore), en vue d'obtenir une importation automatique dans le logiciel 

20 executable. 

Oenerateur de logiciel executable sur mesure 20. Ce generateur utilise les 
donnees du referentiel applicatif, transcrites sous forme numerique. Le generateur 20 
precede en deux etapes : 

- importation 361 (voir figure 3) des donnees du referentiel dans une base de 
25 donnees interne, et 

- generation 362 (voir figure 3) du logiciel executable. 

On observe, en figure 3, que la mise en oeuvre d'un mode particulier de 
realisation du precede objet de la presente invention comporte le mise en oeuvre 
d'un logiciel systeme commun ^ tous les logiciels applicatife et : 
30 - une etape d'initialisation 31 d'un systeme informatique, 

- une etape de representation 32 du processus, mettant en oeuvre un tres petit 
nombre de classes d'actions ou objets generiques. typlquement inferieur e vingt, 
dans au moins un diagramme de I'application, 
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- une etape de transcription 33 de chaque objet de chaque diagramme en une 
action correspondant a un objet dote d'attributs, chaque classe d'action ou objet 
generique 6tant associe a une interface de saisie de donnees d'application, 
comportant, pour programmer chaque action : 

1) une etape de nommage 331 au cours de laquelle on donne un nom a ladite 
action, 

ii) une etape de definition de fonction 332, au cours de laquelle on met ladite 
action en correspondance avec une tache» et, 

iii) une etape de definition dinformation 333, au cours de laquelle on designe 
les informations qui seront traitees dans Taction, 

- une etape de transcription 34 des noeuds, embranchements et feuiHes de 
chaque diagramme en une action correspondant a un objet dote d'attributs, 

- une 6tape de pr§-compiIation 35 au cours de laquelle on verlfie que les attributs 
des objets n§cessaires pour la logique de fonction nement de rapplication existent 
et sont convenablement fournis, en syntaxe, 

- une etape de compilation 36 au cours de laquelle les descriptifs de donn6es des 
objets dotes d'attributs sont integres et sont assembles avec le logiciel systeme. 
pour obtenir un logiciel applicatif executable, et 

- une etape d'execution 37 du logiciel applicatif executable compile au cours de 
Tetape de compilation 36. 

Au cours de Tetape de transcription d'objets, une ou plusieurs action(s) 
lance(nt) un traitement complet se trouvant a un endroit distant d'une arborescence 
correspondant audit au moins un diagramme, et une fois celui-ci termini, retourne a 
son point de depart. 

Pr§ferentiellement, au cours de I'etape d*ex6cution. le logiciel applicatif 
executable met en oeuvre une bibliotheque de gestion du deroulement des 
processus correspondant audit au moins un diagramme. ladite bibliotheque 
constituant un automate 70 qui gere le deroulement des processus et execute les 
operations qui les jalonnent. le deroulement des operations etant defini. dans le 
r6f6rentiel applicatif, a Taide de la methode 10, en decrlvant les flux reels. 
Preferentiellement, au cours de Tetape de compilation ou au cours de I'etape 
d'execution, 11 met en oeuvre le moteur 71 qui comporte un superviseur charge de 
reconnaitre la configuration materielle et de communication. Preferentiellement, le 




moteur 71 gere une ou plusieurs bases de donnees d'apres un descriptif des fichiers 
de donnees fourni par le referential applicatif. c'est-a-dire une liste des informations 
contenues dans chaque fiche et la liste des index d'acces, avec une liste des 
champs servant a constltuer chacun de ces index, les liens entre des codifications 
5 multiples d'un meme item dans plusieurs services, plusieurs sites ou plusieurs 
entreprises. Les bases de donnees sont synchronisees selon une frequence 
determinee par le diagramme, d la demande ou avant certains 6venements 
predetermines. 

Preferentiellement, I'etape de compilation (36) remplace le nom d'action donne 
10 par le transcripteur, au cours de I'etape 33, par un index dans une table de tSches, 

Preferentiellement. au cours des etapes de representation et de transcription, 
ledit au moins un diagramme correspond a au moins une arborescence dans laquelle 
les nceuds et feuilles, oij le code est effectu6, sont composes d'actions, les valeurs 
de retour de ces actions determinant le d^placement dans I'arborescence. 
15 Une fois terminee la generation, le precede peut passer sur I'applicatif d,e 

I'entreprise. chaque processus de I'entreprise etant accessible suivant les droits d^s 

utilisateurs. ~ 

Le referentiel applicatif peut etre modifie. Une nouvelle generation du logici^l 
executable met ^ la disposition des utilisateurs la nouvelle version. Le temjfjs 
20 necessaire d une generation est de I'ordre de dix ^ trente minutes, suivant 
I'importance du processus. 

Etape d'importation 361 des donnees du referentiel dans une base de 
donnees interne. Au cours de cette phase, le generateur 20 contr6le la synthaxe et la 
coherence des donnees fournies par le descriptif de I'application. La presence de 
25 certaines donnees de description obligatoires est contrdlee. Les donnees appelees 
dans les traitements doivent exister: champs d'informations, libelles, messages, 
processus, taches. Si le generateur 20 detecte une erreur. il envoie un message et 
refuse de passer ^ la phase suivante. 

Etape de generation 362. Une fois le referentiel applicatif accepte, le 
30 generateur 20 genere le logiciel applicatif en associant le moteur 71 et les donnees 
applicatives. La fin de cette phase de generation 362 redonne la main ^ Tutilisateur, 
avec la nouvelle version disponible en cas de changements. 

On definit deux classes de structures : 
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- celies qui servent a decrire les informations utilisees dans les applications, 
particuli6rement le format des donnees, la structure des enregistrements dans 
la base de donnees et la fagon dont les ecrans sont presentes, et 

- celles qui correspondent a la fagon dont le programme va se derouler (I'ordre 
dans lequef les traitements vont §tre effectues) : diagramme de flux ou de 
processus et actions sur les flux, 

Les premieres sont des donnees de description et les secondes des donnees 
de d6roulement. 

Les donnees de deroulement comportent : 
a/ les actions 

Les donnees de deroulement ont une organisation particuliere qui a une forte 
incidence sur la fagon de programmer les applications. Une des motivations est 
d'eviter la programmation directe en langage informatique. par exemple en langage 
C. A cet effet, un certain nombre de fonctions de manipulation et de presentation des 
donnees ont et6 definies. Leur ont ete associees un certain nombre d'arguments, 
fixes ou pouvant etre parametres gr§ce a certaines structures de donnees (les 
« cartes » decrites plus loin) et d'empaqueter le tout dans un ensemble Identifie par 
un code, Chaque ensemble porte le nom d' « action ». La structure action est donn6e 
cl-dessous : 

struct action 

{ 

char *ac_name; 
int *ac_fonc 
unsigned long ac_param[MPRM]; 
char *ac_article; 

} 

Programmer une action, dans cet esprit, revient simplement d lui donner un 
nom. affecter la "t§che moteur*' ou "tache type" (par exemple : calcul, comparaison. 
controle, branchements, et designer les informations qui seront trait6es dans 
Taction. 

Les actions sont enchainees suivant leur ordre fonctionnel dans des 
diagrammes. Les actions ramenant toutes a des codes definis, il est possible de 
representer ainsi les structures de controle classiques telles que branchement, 




boucle, test, etc ... Ces controles sont eux-memes effectues par des actions, voir 
plus loin. Deroulement du code dans Tappllcation - Diagrammes de processus. 

Le concept sur lequel le deroulement est base, intimement lie a celui d'action, 
est celui d'arborescence. Ce n'est pas une id§e nouvelle qu'une application a base 

5 de menus soit structuree en forme d'arborescence. Dans notre cas cependant, le 
diagramme a ceci de particulier que ses noeuds et feuilles, oD le code est effectue, 
sont composes d'actions. En fait, chaque noeud est un receptacle oD peuvent tenir 
MACT actions - Le nombre d'actions dans une branche, IVIACT, est un parametre du 
moteur 71. Les valeurs de retour fournies par ces actions, detenninent le 

10 deplacement dans les arborescences. 

On observe qu'assembler un certain nombre d'actions standards en des 
diagrammes dpnne un resultat plus simple a controler que du code C genere 
directement. Le principe etant que des actions, supposees travailler sur des donnees 
convenablement encapsulees, sont considerees comme sures, et leur contenu nja 

15 jamais a etre trace. 'i 
Implementation des diagrammes. 4 
Les noms des diagrammes et les actions jalonnant les diagrammes sprit 
plac6s dans une structure appelee staict branche. La structure branche est decrite 
ci-dessous : 

20 typedef staict branche 

{ 

char nom_digramme[LNOM]; 
unsigned int table_traitements[MACT]; 
char *securite ; 

25 } node; 

Le nom "nom_diagramme" permet d'identifier le diagramme et de se deplacer 
de diagramme en diagramme. Les elements de table_traitements sont des actions 
qui seront executees a Tarrivee sur le diagramme; le concepteur leur donne un nom 
et la compilation remplace ces noms par des index des actions dans une table qui 
30 les regroupe : leur acces est instantane et permet d'obtenir de bonnes performances 
des traitements informatiques. 

La chaTne de caracteres "securite" est examinee avant toute demande 
d*arrivee sur le diagramme. pour permettre d'interdire Tacces en fonction des droits 
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de Tutilisateur de l application. C'est ainsi que certains menus ne seront pas visibles 
pour certains utilisateurs, et visibles pour d'autres. 

On decrit ci-dessous, sur un example, la fagon dont on se deplace dans les 
nceuds et dont on execute le code. 



En arrivant sur ce diagramme, le systeme execute Taction tab_tr[0]. Si elle 
ramfene le code NEXT, comme le font, par exemple les 4 premieres actions du 
diagramme L11, on execute Taction suivante. Si elle ramene DSCD (pour 
« descend »), elle doit aussi avoir positionne une variable globale, Choix. Cette 

10 variable va alors etre concatenee au nom du diagramme courant, pour donner le 
nom du nouveau diagramme. Par exemple, si la variable choix vaut « 1 », on se 
dirige vers le diagramme « LI ». On note DSCD(1) Tassociation de DSCD et de 
choix=1. Uinverse de la procedure se produit si une action retourne RMTE, Dans ce 
cas, Taction doit avoir positionne certains drapeaux (« flags ») internes pour 

15 determiner d quelle action de la branche de remontee on reprend le traitement. Par 
exemple, une remontee a Taction 3 depuis L1 nous positionne sur la quatrieme 
action du noeud L (les actions etant numerotees a partir de 0.) 

Plus precisement, c'est le caract6re ASCII representant le nombre choisi qui 
est additionne. 11 faut done eviter de donner a "Choix" une valeur en dehors de 

20 Tintervalle [a~2A-Z-0-9], afm d'eviter les caract6res invisibles ou dotes de 
fonctionnalites dans la table ASCII. 

On peut enfin passer a une action du meme noeud sans que ce soit 
necessairement la suivante en positionnant NACT plus le numero d'ordre de Taction 
a atteindre par la branche Choix et en retournant NACT. Le traitement se poursuit 

25 tant que Ton n'est pas passe sur une action de sortie, dont la fonction associee est 
de former les fichiers restes ouverts dans la base de donnees et de liberer les 
espaces m6moires. 

On observe que cela ne signifie pas forcement que Ton est revenu a la racine 
ou que Ton a parcouru tout le diagramme ou toute autre condition de cet ordre. II est 
30 aussi possible de sortir « en urgence » de Tapplication avec certaineS routines de 
traitement d'erreurs qui envoient un message et ferment ou cloturent la session. 

On comprend que le systeme. lors du passage dans les menus, interprete les 
entrees clavier. Si une touche de fonction (de F1 a F9 dans la version standard) est 
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Supposons que le nom du diagramme courant soit « L ». 
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tap6e. on descend immediatement sur la branche courante. a laquelle on concatene 
un caract6re entre « 1 » et « 9 ». n peut ainsi tracer le chemin parcouru depuis le 
debut. II exists par ailleurs une variable globale de debuggage. qui affiche. lors des 
parcours des diagrammes, le nom de la branche courante en bas d'ecran et permet 
de contrdler le bon deroulement de la procedure et d'identifier rapidement les erreurs 
commises dans la num^risation des processus. 

Cependant, si une action positionne. par exemple. Choiy & « 7 », rien ne 
permet de savoir, a la lecture des sources du diagramme. si la branche obtenue est 
atteinte suite a une entree clavier, ou suite a un traitement. On conseille au 
concepteur de reserver des valeurs de Choix menu dans I'intervalle [1-9] aux 
branchements obtenus dans un menu, et d'affecter des valeurs alphabetique pour les 
branchements d^clenches automatiquement par le contexe applicafrf. 

On note que si la derniere action d'un diagramme ramene la valeur NEXT, le 
systeme trouve une erreur et s'arrdte. de m§me que si on cherche a descendfB 
lorsque I'on se trouve dej^ sur une feuille, ou si on cherche ^ remonter en §tant d§Ja 
^ la racine. f 
Lancement des diagrammes. P 
Le nom du premier diagramme Ianc6 depend de I'activit6 d§sir§e. 11 est lanqe 
a la fin du main par un appel la fonction ^interpretation de diagramme. Cette 
routine prend bien sQr le nom du diagramme en argument, mais aussi le num§ro de 
Paction qui est ex§cut6e en premier. En effet, on veut parfois 6viter de debuter S 
faction 0, les premieres actions pouvant par exemple effectuer des initialisations 
ind§sirables. On donne aussi les arguments type_arbre et no_arbre qui donneront 
leurs valeurs aux variables tp_arb et no_arb. Ces variables permettent de determiner 
le type de diagramme. c'est-^-dire s'il s'agit d'un diagramme de Saisie. de Liste ou 
d'Impression. pour parler des types standards, ou un autre type si besoin est. 
Comme plusieurs modules peuvent avoir le m§me type (par exemple, les modules 
clients, foumisseurs et articles peuvent dtre tous des Saisies). on les distingue par un 
num6ro d'ordre no_arb. Ce numero depend de la g6n§ration des cartes par le 
gen^rateur 3. Ces variables permettent de relier les tables de param6tres 
personnalis§s d'un module S un processus commun standard (voir saisies de fiches 
simples ou de fiches de listes, impression, d^clenchements d'alerte). 
Lancement de diagrammes particuliers 
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II est parfois interessant, depuis une action donnee. de lancer un traitement 
complet se trouvant a un endroit distant de I'arborescence. et une fois celui-ci fini. de 
se retrouver d son point de depart. Cela est rendu possible par le fait que, bien que 
tous les diagrammes de {'application soient regroupes dans un meme tableau, celui- 
ci regroupe en fait une foret. On peut lancer une arborescence nouvelle comme un 
lien avec un « sous-processus » ou "sous-syst^me" en terme cybernetique, a Taide 
de Taction de lancement d'un diagramme. tout connnne « mainQ » lance le 
diagramme initial. C'est mdme ainsi que les divers modules sont integres a 
Papplication. On utilise un diagramme existant d^crivant un module, on lui donne un 
nom, et, depuis notre arborescence d'origine, on lance le diagramme en question. 
On sort de ce diagramme particulier par une action ramenant ENDA. 

Diagrammes clients et diagrammes communs 

Les diagrammes clients sont des diagrammes sp6cifiques a une application. 
Les diagrammes communs sont des « objets proceduraux », permanents et 
accessibles par Tappel a des cartes Identifiant les travaux a realiser et les 
infonnations n6cessalres pour obtenir le deroulement d'une procedure sp6cifique 
suivant un modele standard (objet procedural) : nom des fichiers et ecrans, noms 
des menus et messages, diagrammes de traitement ^ ex^cuter a des moments 
precis de la procedure (par exemple : fin de la selection d'une fiche a mettre a jour). 
Certains ensembles de traitements vont etre utilises dans toutes les applications. Par 
exemple, les processus de saisie de liste, de Saisies, d'impressions. etc ... sont 
communs. Dans le cas des Saisies, par exemple, on a toujours un menu proposant 
un choix de type : 

CREATION 

MISEA JOUR 

CONSULTATION 

SUPPRESSION 

FIN 

puis, apr§s selection de MISE A JOUR, on a un choix. par exemple : 
PREMIER 
DERNIER 
SELECTION 
FIN 




puis, aprds selection de PREMIER, par exemple : 
PREMIER 
DERNIER 
SUIVANT 
5 PRECEDENT 
SELECTION 
VALIDATION CHOIX 
FIN. 

Les deroulements de ces diagrammes sont fixes de fagon permanente dans 

10 des procedures standard. II suffit de fournir les identificateurs d'ecrans et de fichiers 
utilises, et ces diagrammes vont les visualiser, modifier les menus au fur et a mesure 
des 6tapes. etc... Le m6canisme de la procedure est toujours identique. mais son 
contenu est adapte, sur mesure, aux besolns exprimes par les utilisateurs. Bjen 
entendu. un certain nombre de points d'entree subsiste pour inserer des actions 

15 particulieres S chaque client, par exemple si le mode de lecture des donnees est i^ps 
particulier (par exemple, si le fichier n'est pas un fichier standard mais est impo'^6 
d'un autre syst^me. la fagon de lire la premiere fiche n'est pas standard, done dpit 
§tre donn6e par le concepteur). Par centre, le fait d'avoir le choix de demandei^,4a 
premiere fiche reste standard, done le diagramme considers est utilisabje. 

20 L'ensemble. des informations propres ^ chacun des applicatifs est r6unl de fagon 
structur§e dans des "cartes" (voir ci-apres) : le concepteur "cable" une carte pour 
approprier le processus standard a chaque processus particulier 

Les traitements particuliers ^ certains clients qui ne sont pas generalisables 
sont codes sous forme de diagrammes specifiques et d'actions. Ceux-ci ont 

25 exactement la m§me structure que les diagrammes standards, mais sont places 
dans un tableau secondaire, done ne sont pas compiles avec les applications n'y 
acc6dant pas. Notons que la recherche des noms diagrammes par le systeme 
commence toujours par les diagrammes clients. II est ainsi possible de d6flnir son 
propre diagramme client et de lui donner le m§me nom qu'un diagramme commun 

30 dent on n'appr^cie pas le comportement. C'est le diagramme client qui sera pris ^ la 
place. On ne peut, en revanche, demander explicitement a utiliser la version client ou 
la version commune d'un diagramme. 

Lancement d'actions supplementaires 
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Parfois, le nombre d'actions maximal d'un diagramme n'est pas suffisant pour 
effectuer un traitement. II existe plusieurs m^thodes pour r^gler ce type de 
probl^mes. On peut aussi lancer une action particuli^re qui permet de se rebrancher 
sur un diagramme avec un retour d I'action sulvant Taction de branchement 
(hypemavigation). 

Sur chaque champ d'ecran, on peut declencher des diagrammes, d I'entr^e du 
champ et ^ la sortie (attribution de valeurs, calculs Instantanes, ..,) 
Cartes 

Les cartes sont des ensembles de parametres permettant d'orchestrer le 
comportement des diagrammes qui lui sont relatifs. Elles regroupent ia plupart des 
informations utiles pour la gestion des divers modules constitutifs d'une application, 
par exemple le nom des fichiers concem§s, des ecrans de Saisle, d'en-tete et de 
liste si besoin est, les noms des champs de cle pour les lecrfures/ecrltures de 
donn^es, des. drapeaux (flags) de contr6le de traltements, les noms des menus § 
afficher en bas des ecrans. les actions specifiques a lancer dans le d§roulement des 
diagrammes, etc ... 

Une carle est une structure regroupant un certain nombre d'entrees 
num6riques non sign^es, et un certain nombre de chaTnes de caracteres. Nous ne 
consld6rons que le cas des donndes numeriques, la discussion etant similaire pour 
les cartes concernant des donnees de type « caractere ». 

On distingue, en general trois types de cartes, correspondant aux trois grands 
types de traitement, les cartes de Saisies, les cartes de Listes et les cartes 
d'impression. La difference entre chaque type reside seulement dans le nombre et la 
signification des entrees de la structure ie representant. 

L'identification de ces cartes est donn^e par deux parametres tp_arb et 
no_arb. connus d tout instant par I'envlronnement de navigation, et permettant de 
savoir dans quel type de module de I'application I'utillsateur travaille (saisie simple, 
saisle de liste, Impression. ... et sur quel sujet : article, stocks ...). 

Toutes les structures cartes d'un type donn§ sont regroup6es dans un tableau 
(on a done trois tableaux principaux), et une table de regroupement, cart[], regroupe 
les structures pointeurs de chaque tableau. L'ordre des divers types de cartes dans 
ce tableau est le suivant : 
0 Reserve 
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1 Saisie des listes 

2 Saisie simple 

3 Reserve 

4 Impressions 
5 5 R6serv6 

On decrit ci-apr6s comment referencer un param^tre dans une carte. Chaque 
donnee d'une carte est identifi^e dans les actions standards sous la forme : type de 
parametre (numerique ou alpha) x 1 000 + num§ro d'ordre du parametre dans le 
descriptif de la carte, par exemple 58. Le coeur du moteur 71 reconnalt que la 

10 donnee provient de la carte en cours et fait une double indirection vers la carte du 
processus en cours, puis vers la 58® position dans cette carte. Ce traitement est 
automatlquement fait par I'executeur d'actions, fournissant ainsi k celles-ci les 
bonnes valeurs. Ce type d'interpretation est fait non pas par I'action elle-meme, mais 
par le m6canisme d'interpretation des diagrammes du coeur du moteur 71 . « 

15 Ce principe permet, par exemple. ^ une meme action de visualisation 

d'afRcher des 6crans diff6rents suivant la carte dans laquelle on se trouve, tout $n 
conservant les memes paramdtres d'appel. 11 sufRt d'avoir modifie auparavant Ja 
table de parametres indexes. 

Ce type d'interpretation est fait non pas par Taction e!le-m§me. mais parole 

20 m§canisme d'interpretation des diagrammes ("cablage" de la carte). En d'autres 
termes, une action comporte des donnees soit decrites de fa^on specifique soit 
decrites par des parametres (carte + numero dans la carte). 

Si les cliamps sont des champs de cles, le nceud peut proceder a des tests 
pour verifier leur validite (la fiche doit exister en mode "mise a jour" et ne doit pas 

25 exister en mode "creation"). Les fonctions de saisie standard vont ensuite passer sur 
tous les champs sauf sur les champs de cl6s. Apr§s la creation de la cle ou la 
selection d'une fiche en mise ^ jour, la procedure passe dans une phase de saisie 
courante et traite les champs accessibles. 
Niveau 

30 Une liste de structures chaTnees allouees dynamiquement par le systeme 

permet d'obtenir, ^ tout moment, des informations interessantes concemant I'^tat 
courant de I'application. Ces structures dites structures niveau, regroupent 
notamment : 



- le nom du diagramme courant (nom) 

- rindex de Taction dans le diagramme courant (nact) 

- le nom de la carte (tp_arb) 

- rindex de la carte dans la table des cartes (no_arb) 

Le syst^me alloue une telle structure a chaque descente ou a chaque lancement 
d'un diagramme. Les structures sont liberies en fin de diagramme ou apres 
remont6e. 

Transferts. insertions et extractions 

Uessentiel des traitements effectues consiste en transferts d'information d'une 
zone vers une autre, par exemple d'un champ de fichier. apres la lecture d'un 
enregistrement, vers un champ d'ecran permettant la visualisation de Tinformation 
consid6ree. Les structures d'6crans/fichiers permettent jusqu*a trois codages de 
transferts. Un codage tient sur un unsigned int (32 bits) et a I'aspect suivant : 

type de la donnee (fichier, §cran), nom du fichier ou de Tecran, nom du 
champ. 
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REVENDICATIONS 



1 - Proced6 de g6n6ration de loglciel appllcatif de gestion d'un processus, 
caracterise en ce qu'il met en oeuvre un logiciel systeme commun ^ tous les logiciels 
5 applicatifs et en ce qu'il comporte : 

- une etape de representation du processus (32). mettant en oeuvre un tres petit 
nombre de classes d'actions ou objets g§n6riques, typiquement infSrieur & vingt. 
dans au moins un diagramme de I'application, 

- une etape de transcription (33) de chaque objet de chaque diagramme en une 
10 action con-espondant a un objet dote d'attributs. chaque classe d'action ou objet 

g6n6rique etant. pendant I'^tape de transcription, associ6 a une interface de 
saisie de donn6es d'application, 

- une 6tape de transcription des noeuds, embranchements et feuilles (34) de 
chaque diagramme en une action correspondant S un objet dote d'attributs, 

15 - une etape de pr6-compilation (35) au cours de laquelle on v6rifie que les 
attributs des objets necessaires pour la logique de fonctionnement de I'applicatipn 
existent et sont convenablement fournis. en syntaxe, 

- une etape de compilation (36) au cours de laquelle les descriptife de donn^es 
des objets dotes d'attributs sont integr§s et sont assemble avec le logiciel 

20 systeme, pour obtenir un logiciel applicatif executable, et 

- une etape d'execution (37) du logiciel appllcatif executable. 

2 - Precede selon la revendication 1, caracterise en ce que, au cours de I'etape de 
transcription d'objets (33), au moins une action lance un traitement complet se 
trouvant a un endroit distant d'une arborescence conrespondant audit au moins un 

25 diagramme, et une fois oelui-ci termini, retourne d son point de depart. 

3 - Proc6de selon I'une quelconque des revendications 1 ou 2, caracterise en ce que. 
au cours de I'etape d'ex6cution (37). le logiciel applicatif executable met en oeuvre 
une biblioth^que de gestion du d^roulement des processus correspondant audit au 
moins un diagramme. ladite bibliothdque constituant un automate (70) qui gere le 

30 deroulement des processus et execute les operations qui les jalonnent, \e 
deroulement des operations etant defini, dans le referentiel applicatif, § I'aide de la 
methode (10), en decrivant les flux reels. 
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4 - Precede selon I'une quelconque des revendications 1 a 3, caracterise en ce que, 
au cours de I'etape de compilation (36) ou au cours de I'etape d'execution (37), il met 
en oeuvre un moteur (71) qui comporte un superviseur charge de reconnaitre la 
configuration materieile et de communication. 
5 5 - Procede selon la revendication 4, caracterise en ce que le moteur (71) gere une 
ou plusieurs bases de donnees d'apres un descriptif des fichiers de donnees fourni 
par le referentiel applicatif, c'est-a-dire une liste des informations contenues dans 
chaque fiche et la liste des index d'acces, avec une liste des champs servant a 
constituer chacun de ces index, les liens entre des codifications multiples d*un meme 
10 item dans plusieurs services, plusieurs sites ou plusieurs entreprises. 

6 - Procede selon la revendication 5, caracterise en ce que les bases de donnees 
sont synchronisees selon une frequence determinee par le diagramme, a la 
demande ou avant certains 6v6nements predetermines. 

7 - Procede selon Tune quelconque des revendications 1 a 6. caracterise en ce que 
15 I'etape de transcription d'objets (33) comporte. pour programmer chaque action : 

- une 6tape de nommage (331) au cours de laquelle on donne un nom a ladite 
action, 

- une etape de definition de fonction (332), au cours de laquelle on met ladite action 
en correspondance avec une tache, et, 

20 - une etape de definition d'information (333), au cours de laquelle on designe les 
informations qui seront traitees dans Taction- 

8 - Procede selon la revendication 7, caracterise en ce que I'etape de compilation 
(36) remplace le nom d*action donn§, au cours de I'etape de nommage (331), par le 
transcripteur, par un index dans une table de taches. 

25 9 - Procede selon Tune quelconque des revendications 1^8, caracterise en ce que, 
au cours des etapes de representation (31) et de transcription (32, 33), ledit au 
moins un diagramme correspond a au moins une arborescence dans laquelle les 
noeuds et feuilles, oD le code est effectue, sont composes d'actions, les valeurs de 
retour de ces actions determinant le deplacement dans I'arborescence. 
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